MIPS ABI Problem Resolution Procedure

Definitions
Background
Current Status of Generation and Reference Platforms
Problem Resolution Procedure

• Assessing if the Application Has a Bug
  
• Determining if the Application is ABI Compliant
  
• Testing on the Reference Platform
  
• If the Application Fails on the Reference Platform
  
• Rights of Appeal
  
• Porting Support
  
• Diagram: Problem Resolution Procedure
  

Concurrent Computer
Control Data Systems
Dansk Data Elektronik
NEC
Pyramid Technology
Siemens-Nixdorf
Silicon Graphics
Sony Corporation
Tandem Computers

Introduction

This document describes the procedure an independent software vendor (ISV) should use to resolve problems related to porting and supporting applications for the MIPS ABI. It consists of two components:

• The Policies and Procedures used by the MIPS ABI to identify and resolve technical problems

• The Policies and Procedures for each MIPS ABI member company

The intent of this document is to provide ISVs with an understanding of how the ABI group works together to identify, classify and correct technical problems relating to the ABI specification, its interpretation and/or its implementation on various MIPS ABI member company platforms.

The MIPS ABI is dedicated to working with our ISVs to ensure complete customer satisfaction. We realize that we share in common, customers who are equally dependent upon both ISVs and system manufacturers for their complete solutions and success. As such, the goal of the MIPS ABI is to enable both the ISVs and the systems vendors to quickly and successfully resolve any technical problems associated with the MIPS ABI.

Return to document contents

Definitions

The following terms used in this document may be unfamiliar:

ABI

Application Binary Interface. The set of supported interfaces available to applications to ensure compliance across multiple platforms.

ACTS

Application Conformance Test Suite. The set of tests used to check an application for use of non-ABI features. While no software test can be considered to be 100% complete in its ability to ensure compliant code, the MIPS ABI is continuously refining and extending these tests. The ACTS is provided on each generation platform system.

Compliant System

Any system which is binary compatible with the MIPS ABI specification. Compliance is the responsility of the individual system vendor and is verified by both careful analysis of each application environment and the use of test suites.

Generation Platform

The platform on which the application is built. Not all MIPS ABI compliant systems are suitable as generation platforms. For a list of currently approved generation platforms, contact any MIPS ABI Group company.

MIPS ABI

The ABI supported by vendors of SVR4.x-based systems which use the MIPS family of RISC processors.

MIPS ABI Group

The vendors of platforms who have agreed to cooperate to produce and enhance the MIPS ABI and produce compliant systems which conform to it.

MIPS ABI Black Book

The document which defines the MIPS ABI. It references a Conformance Guide number of other documents which define particular pieces of the ABI. It is frequently referred to as the Black Book for historical reasons.

Reference Platform

The software platform chosen as the standard implementation of the MIPS ABI. It is also the final arbiter for any problems which cannot otherwise be resolved by using the gABI, psABI and/or Conformance Guide. Barring other determinants, the performance of an application on the reference platform is presumed to be correct. Note that a Generation Platform is not to be confused with the Reference Platform. Only the Reference Platform can be used as the final arbiter for problem resolution.

Return to document contents

An application correctly ported to the MIPS ABI should run, without modification, on a wide variety of MIPS ABI compliant systems. ISVs wanting to port their applications to the MIPS ABI should access an approved application generation platform (or the MIPS ABI reference platform) and should reference the MIPS ABI Conformance Guide, Frequently Asked Questions (FAQ) and any supplemental technical bulletins. These are available from any MIPS ABI Group vendor. In addition, ISVs should reference the generic ABI (gABI) and the MIPS processor supplement (psABI) to the generic ABI and the System V Interface Definition (SVID) edition 3, all of which are publicly available. Conceptually, the MIPS ABI Conformance Guide is a set of extensions to the psABI for MIPS processors which is itself an extension of the gABI for UNIX SVR4.x. As such, an ISV must follow the guidelines of all three documents to produce an application which is MIPS ABI compliant.

ISVs should completely test and QA their MIPS ABI applications on one or more approved generation platforms. ISVs should also use the ACTS to determine if any non-ABI coding was used that would violate the MIPS ABI, gABI and/or psABI.

The MIPS ABI Group selected a reference platform model to implement the MIPS ABI. This model offers ISVs significant advantages over alternative models including the virtual reference model that has used by other ABI organizations. The very nature of an ABI reference model system places responsiblity on the system vendors to ensure that their systems comply with the ABI specification, and on ISVs to ensure that their applications conform to ABI guidelines. The MIPS ABI group's use of a reference model system guarantees to ISVs that ownership of any problem can be determined quickly so that the problem may be quickly identified and corrected. The reference system is used to resolve any ambiguity which may exist in the gABI, psABI or MIPS ABI Conformance Guide.

The MIPS ABI Group has also specifically chosen not to certify applications for compliance. This choice was made for several reasons:

Practicality

It is not practical for ISVs to send their applications to an independent or MIPS ABI test center. The expertise for any given application resides with the ISV, not a testing organization who cannot fully understand or master thousands of applications from hundreds of vendors. Nor can such an organization effectively manage such a task in timeframes that are acceptable to either the ISV, the customer or the system vendors.

Test Suites

While the MIPS ABI Group provides test suites to assist ISVs in determining whether or or not their application utilizes non-ABI features, the best test suites are those that are developed and administered by the ISVs themselves.

Responsibility

The ISV and the MIPS ABI Group system vendors must together take responsibility for the success of the applications and of the ABI. An outside agency cannot take responsibility for the conformance or performance of an application.

The MIPS ABI Group does ask that ISVs successfully pass the ACTS and then notify the MIPS ABI Group marketing coordinator. This allows the MIPS ABI Group to promote only those applications which have followed the MIPS ABI Conformance Guide and porting guidelines. However, in no way does the MIPS ABI Group certify any application's compliance or guarantee its performance on any given system. What the MIPS ABI Group does guarantee is to work with our ISVs, our customers and each other to promptly address and resolve any technical problems that might arise.

Return to document contents

ISVs should contact any MIPS ABI member company for a current list of supported generation and reference platform hardware and software. An online version of this list may be found at http://www.mipsabi.org/Mktg/Conformant.

This document assumes that any problem experienced by a customer relating to application software will first be reported by the customer to the ISV. A problem may reach the ISV either directly, as a result of a difficulty in using the software, or indirectly, from a distributor of the software. In either case, it is the ISV who should follow the procedures described in this document.

Assessing if the Application Has a Bug

The ISV should first determine whether the problem is related to the application itself. This can be done by checking for known bugs in the application or testing the application on a non-MIPS ABI platform of the ISV's choice to determine if the problem can be easily recreated. If the ISV can reproduce the problem on a platform of their choosing, the problem is assumed to be in the application and the ISV is responsible to correct the problem.

Determining if the Application is ABI Compliant

If the problem cannot be recreated on a non-MIPS ABI system (i.e. the application performs correctly), the ISV should ensure that their application is MIPS ABI compliant and that it has not used any code or facilities not supported by the version of the ABI implemented. This can be determined by use of the ACTS and by referencing the gABI, psABI and MIPS ABI Conformance Guide. This means that the application can only use the interfaces, libraries, commands and file formats specified in the MIPS ABI Conformance Guide, psABI and gABI. The ACTS should be performed on all applications before the ISV ships them. Many problems are due to applications attempting to utilize a facility not supported by the Conformance Guide and/or the ABIs.

If the application was not developed in conformance to the MIPS ABI Conformance Guide, the ISV should modify the port of their application so that it is in compliance with the specification.

Testing on the Reference Platform

If it appears that the application does conform to the MIPS ABI Conformance Guide and passes the ACTS, the ISV should then attempt to recreate the problem on a MIPS ABI reference platform. (If the ISV does not have such a system at their location, they should contact the customer's platform supplier for assistance in accessing a system.) If the problem cannot be recreated on the reference platform (i.e. it performs correctly), the problem is assumed to be with the vendor of the system on which the application fails. The ISV should contact the system vendor immediately.

MIPS ABI system vendors are aware that a problem may also exist on other platforms. As such, they will immediately notify the MIPS ABI group so that any problem can be corrected on all offending platforms. Each platform vendor will also notify the MIPS ABI group regarding any ambiguities in the Conformance Guide.

The ISV should consult the second section of this document for information on contacting each particular compliant system vendor and for information on their respective technical support policies.

Generation platforms are designed be used for generating MIPS ABI compliant binaries. While they can be used for determining problem resolution, it is more efficient to access a reference platform, which can immediatly determine the cause for the problem.

If the Application Fails on the Reference Platform

If the application fails on the reference platform the problem is known to be either that:

1. There is ambiguity in the Conformance Guide and/or the ABIs or the particular matter in question is not defined. (For example, a system call used by the application is not mentioned as supported or unsupported by the Conformance Guide or the ABIs.) If this is the case, the reference platform behavior is presumed to be correct and the ISV should modify their application so that it executes properly on the reference platform. Each MIPS ABI system platform vendor will then modify their platform so that they are compliant with the reference platform in this regard.

2. There is no ambiguity in the Conformance Guide and/or ABIs and the reference platform is clearly not conforming to the gABI, psABI or Conformance Guide. If this is the case, the reference platform must be modified to conform to the MIPS ABI Conformance Guide so that the application, which is presumed to be correctly ported, can be properly executed. The MIPS ABI Group will also ensure that any other system vendors modify their systems as necessary.

3. The Conformance Guide and/or the ABIs are in error or contradict each other and must be corrected. The MIPS ABI Group will modify the Conformance Guide as appropriate. The ISV should should modify their application so that it executes properly on the reference platform.

Rights of Appeal

Any ISV who feels that the process is not being properly adhered to or disagrees with an implementation or specification component has the right to appeal to the MIPS ABI Group. This can be done either by contacting any member of the MIPS ABI Group or by sending email to the MIPS ABI Technical Support Program at mipsts@engr.sgi.com. The MIPS ABI Groups technical staff are in frequent contact with each other via email and will acknowledge and respond to all ISV requests within one business day.
ISVs should not use this email address to request technical support or porting assistance. Please refer to section 4.6

Porting Support

ISVs who are porting to the MIPS ABI should be members of the SGI Developer Program. The SGI Developer Program provides technical and marketing assistance to all qualified developers. To become a member of the Developer Program, developers must complete a Developer Program Application, pay an annual membership fee and have products which will be available within one year of the date of registration.

ISVs who are members of the SGI Developer Program may direct their technical support questions to devprogram@sgi.com. All email requesting ABI technical support, should include 'ABI' in the email's subject line.

In addition to technical support, developers will also receive the Developer News, Developer Toolbox CD-ROM, system software updates, Applications Directory entry, development product discounts, access to porting centers and other benefits. For more information, ISVs may contact any of the MIPS ABI Group member companies or contact the SGI Developer Program directly at:

MIPS ABI Companies
Technical Support Policies and Contacts

Concurrent Computer Corporation is a leading worldwide supplier of networked and distributed, high performance, real-time, fault-tolerant computing systems. Concurrent offers products and services for real-time solutions in weather and airspace management, simulation and training, signal intelligence and analysis, measurement and control, and other markets.

Concurrent provides ISVs with full technical support, both during the porting of the products and throughout the life cycle of their products on Concurrent platforms.

Concurrent is an active member of the MIPS ABI group. The recent release of the MAX/OS, based on SVR4.2MP, is compliant with the MIPS ABI specification.

Support Policy

ISV porting and technical support issues are managed through our technical support center in Oceanport, NJ. The support center works closely with operating system and networking engineering groups in Westford, MA., and in England.

Issued will be acknowledged and often resolved within one business day. Software problem reports will be acknowledged within one day, and are then classified as one of the following:

	1) Severe:    no useful work is possible
	2) Serious:   some work is possible
	3) Moderate:  most work is possible
	4) Minor:     all work is possible

If an update or patch is required for a level 1 or 2 problem, an estimate of the delivery time will be provided. These patches are normally provided in the 'pkgadd' format for easier update and control of the Concurrent platform.

Technical Support Contact

ISVs should contact Concurrent Technical Support Center at 800-732-2737, and identify themselves as part of the ABI program. The Center is staffed during normal business hours, 8:00am-5:00pm (local US time). Calls are logged 24 hours a day, 7 days a week.

Return to document contents

As an integral part of its support services, Control Data offers software support which incorporates its long history of solving customers' complex computing problems. Unique among systems integrators, Control Data has its own fully trained professional staff of technical experts who can provide high quality software support for any Control Data-implemented solution. To ensure that this quality service level is monitored and continually improved, we survey our customers on an ongoing basis.

We offer flexible software support for the diverse needs of our systems integration customers. Backed by a highly capable staff of support professionals, Control Data delivers a wide range of support options such as:

• Hotline Support Service
  • Technical Support
  • Diagnostic Tools
  • Emergency Remote Technical Assistance (RTA) Support
  • Management Escalation Process
• Software Updates
• Access to SOLVER Database
• Remote Hotline Consulting (Additional Option)
• Installation (Additional Option)

By checking the boxes on the Service Order which correspond to the offerings below, you can customize the software support which best meets your business needs for operating systems, applications or software development.

    1) Severe:  	development has stopped
    2) Critical:  	serious problem but a workaround presently 
			exists, or vendor can continue to work
    3) Small Problem:  	product can be released with or without
			fix to problem

    Priority 1:	Catastrophic failures. 
                The system cannot be used for any meaningful work.
    Priority 2:	Major loss of functionality
    Priority 3:	Minor loss of functionality
    Priority 4:	Nuisance

1.  Technical Support:      Quick Response and Close Relationship to ISVs
			          % Consulting by Engineering Specialist
			          % Reply to Technical Question/Request

2.  Technical Information:   Technical Manual
			          New Product Information
			          Developer's Conference

3.  Release of NEWS-OS:       The latest OS (inc. Early Access) Information

4.  Porting Environment:      Special Price Offer for Porting Machine

1.  Application Information (CD-ROM Disk)

2.  Seminar/Exhibition